/usr/lib/gimp/3.0/plug-ins/file-jpeg/file-jpeg: fatal error: Segmentation fault

xflock4
Error org.freedesktop.DBus.Error.UnknownMethod: No such method “Lock”

dbus-send --session --print-reply --dest=org.freedesktop.ScreenSaver /org/freedesktop/ScreenSaver org.freedesktop.ScreenSaver.Lock
Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ScreenSaver was not provided by any .service files

[...]
2026-07-10T09:11:47.886229+02:00 bacon kernel: __vm_enough_memory: pid: 13377, comm: wrapper-2.0, bytes: 16361543696384 not enough memory for the allocation
2026-07-10T09:11:52.886230+02:00 bacon kernel: __vm_enough_memory: pid: 13377, comm: wrapper-2.0, bytes: 16361610805248 not enough memory for the allocation
2026-07-10T09:11:57.888228+02:00 bacon kernel: __vm_enough_memory: pid: 13377, comm: wrapper-2.0, bytes: 16361677914112 not enough memory for the allocation
2026-07-10T09:12:02.888234+02:00 bacon kernel: __vm_enough_memory: pid: 13377, comm: wrapper-2.0, bytes: 16361745022976 not enough memory for the allocation
2026-07-10T09:12:07.887228+02:00 bacon kernel: __vm_enough_memory: pid: 13377, comm: wrapper-2.0, bytes: 16361812131840 not enough memory for the allocation
[...]

● Root cause fully confirmed at both the code and runtime level. Here's the diagnosis.
  
  Root cause
  
  It's not a bug in xscreensaver's logic — it's a stale local PAM config that a behavior change in 6.15 now trips over.
  
  What changed (6.09 → 6.15, driver/passwd-pam.c):
  
  In 6.09, the result of the account phase (pam_acct_mgmt()) was stored in a throwaway status2 and ignored on Linux (it was only honored if built with --with-pam-check-account-type, i.e. PAM_CHECK_ACCOUNT_TYPE):
  
  status2 = pam_acct_mgmt (pamh, 0);
  ...
  #ifdef PAM_CHECK_ACCOUNT_TYPE
     status = status2;      /* not defined on this build → ignored */
  #endif
  
  In 6.15 jwz deleted that logic ("I'm going to assume that this nonsense is no longer ongoing. -- jwz 2025") and now the account result is the final result:
  
  status = pam_acct_mgmt (pamh, 0);   // 6.15
  ...
  return (status == PAM_SUCCESS);
  
  Why that fails on this box: /etc/pam.d/xscreensaver (a MarIuX file dated Aug 2012) contains only auth lines — no account stanza. When a service file lacks a module group, Linux-PAM falls through to
  /etc/pam.d/other, which is account required pam_deny.so. So pam_acct_mgmt() returns PAM_AUTH_ERR.
  
  Empirical proof (no password needed)
  
  pam_acct_mgmt() requires no password, so I reproduced it directly with a 30-line libpam probe:
  
  Service xscreensaver: pam_acct_mgmt = 7 (Authentication failure)   ← the "auth failed" you see
  Service login:        pam_acct_mgmt = 0 (Success)                  ← login has an account stanza
  
  Flow in 6.15: pam_authenticate() succeeds (correct password) → pam_acct_mgmt() returns 7 → return (status == PAM_SUCCESS) is False → "authentication failed". In 6.09 the 7 was discarded, so it worked.
  
  The fix
  
  Add an account stanza to /etc/pam.d/xscreensaver (requires root — I don't have it here). Mirror the system's login/system-auth:
  
  account     required       pam_access.so
  account     required       pam_unix.so
  
  status = pam_acct_mgmt (pamh, 0);   // 6.15
  ...
  return (status == PAM_SUCCESS);
  
  Why that fails on this box: /etc/pam.d/xscreensaver (a MarIuX file dated Aug 2012) contains only auth lines — no account stanza. When a service file lacks a module group, Linux-PAM falls through to
  /etc/pam.d/other, which is account required pam_deny.so. So pam_acct_mgmt() returns PAM_AUTH_ERR.

  Empirical proof (no password needed)

  pam_acct_mgmt() requires no password, so I reproduced it directly with a 30-line libpam probe:

  Service xscreensaver: pam_acct_mgmt = 7 (Authentication failure)   ← the "auth failed" you see
  Service login:        pam_acct_mgmt = 0 (Success)                  ← login has an account stanza
  
  Flow in 6.15: pam_authenticate() succeeds (correct password) → pam_acct_mgmt() returns 7 → return (status == PAM_SUCCESS) is False → "authentication failed". In 6.09 the 7 was discarded, so it worked.
  
  The fix
  
  Add an account stanza to /etc/pam.d/xscreensaver (requires root — I don't have it here). Mirror the system's login/system-auth:
  
  account     required       pam_access.so
  account     required       pam_unix.so
  
  That's the minimal correct fix. login uses exactly these two and my probe showed they return Success for your user, so this resolves it. (For completeness you may also add password required pam_unix.so md5
  shadow to cover expired-password changes, but the current failure is fixed by the account lines alone.)
  
  This is really a packaging bug in the MarIuX xscreensaver beebuild: the shipped 6.15 driver/xscreensaver.pam uses account include login (which would work), but the box carries a stale hand-written
  /etc/pam.d/xscreensaver from 2012 that predates when the account phase mattered. The proper long-term fix is to update the packaged /etc/pam.d/xscreensaver.
  
  ---
  I couldn't apply the fix myself (no write access to /etc/pam.d, no passwordless sudo). Would you like me to:
  
  1. Write out the corrected /etc/pam.d/xscreensaver to a temp file so you can sudo cp it into place, or
  2. Locate where the beebuild installs its pam file so the package can be corrected at the source?